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Description 

Background of the Invention 

The invention relates to updating link state informa- 
tion in networks. 

Information is communicated through such a net- 
work along a myriad of links which interconnect nodes. 
The nodes may be routers, which receive and forward 
packets toward their destination along the appropriate 
links. Each router must know the states (e.g., operative 
or inoperative) of the links in the network in order to send 
packets along effective paths to their respective desti- 
nations, avoiding, for example, faulty links or routers. 
Schemes for communicating link state information and 
choosing effective (e.g., optimum) paths are known as 
routing algorithms. 

In popular routing algorithms such as that described 
in "The New Routing Algorithm for the ARPANET" by 
McQuillan, Richer, and Rosen, IEEE Transactions on 
Communications , May, 1980, each node (e.g., router) 
determines which links are connected to it, the state of 
those links, and the identity of the node on the other end 
of each link. To initialize the network, each router places 
this information in a special packet known as a Link 
State Packet (LSP), and transmits this LSP to ail of the 
other routers in the network. Later, when changes in the 
network occur (e.g., a link fails), one or more routers 
may generate new LSPs which supersede previously 
generated LSPs. As long as the most recent LSPs are 
propagated reliably to ail of the routers, each router will 
have complete information about the current topology 
of the network and can thus use any well known algo- 
rithm to compute routes through the network (such as 
the Dijkstra algorithm described in "A Note on Two Prob- 
lems in Connexion with Graphs" by Edsgar Dijkstra, Vol. 
1, 1959, pages 269-271). However, if the transmission 
of LSPs becomes unreliable, then the network may 
eventually become incapable of transmitting data. 

When a router receives an LSP, it compares the rel- 
ative ages of the received LSP and any stored LSPs that 
were previously received from the same router. The re- 
ceived LSP is stored in place of the stored LSP if the 
received LSP is more current; otherwise, the stored LSP 
is retained and the received LSP is ignored. To allow 
routers to make a determination of the relative ages of 
LSPs, every LSP is assigned a sequence number; the 
sequence number of each LSP is greater than that of 
the LSP that preceded it. 

Referring to Fig. 1 , a typical LSP includes a source 
field 10 containing the name of the router that originated 
the LSP; a sequence number field 12 containing the se- 
quence number for the LSP; and any number of neigh- 
bor fields 14, each of which indicates a neighbor node 
connected to the source router by a communications 
link. 

When changes occur (e.g., the links connected to 
a router become operative or inoperative), a new ver- 



sion of the router's LSP is issued. In known LSP algo- 
rithms, to reflect these changes, fields are removed from 
or added to the LSP. In known LSP-based routing algo- 
rithms, when a link connected to a router fails, the field 

s corresponding to the link (i.e., the field indicating the 
neighbor to which the link connects) is removed from 
the router's LSP, and the router's LSP is retransmitted. 
When a link returns to operation, the field corresponding 
to the link is added back to the LSP, and the LSP is re- 

10 transmitted. 

In one algorithm for adding and removing fields from 
a LSP, when a field is removed, each of the fields below 
the removed field is moved to a position one field nearer 
to the beginning of the LSP. When a field is added, it is 

is added to the end of the LSP. Thus, when a field near the 
beginning of the LSP is removed, most of the other fields 
in the LSP are repositioned. 

The LSPs stored by two routers are often compared 
to determine if the LSPs being stored by one router are 

20 more recent than the LSPs being stored by one of its 
neighboring routers. Sometimes ail of the LSPs being 
stored by two neighboring routers are compared. To ac- 
complish this, one router forms a complete sequence 
number packet (CSNP) that lists all of the sequence 

25 numbers of all of the LSPs currently stored by the router. 
Referring to Fig. 2, a CSNP contains the sequence 
number field 12 of each LSP stored in the database of 
the router that generated the CSNP. However, these se- 
quence numbers cannot be interpreted without also 

30 knowing the identity of the router that generated the se- 
quence numbers. Therefore, the source field 10 of each 
LSP is paired with the sequence number 12 of the LSP 
(forming a pair 16). 

In a large network, a router may be connected to 

35 many communications links, making that router's LSPs 
very long. Furthermore, there may be many nodes, and 
thus the CSNPs may also become very large. In gener- 
al, the longer a packet, the more difficult it is to transmit 
the packet over a network. 

40 Some network protocols establish a maximum size 
for packets to be transmitted. For example, on a local 
area network (LAN) configured in accordance with the 
IEEE 802.3 protocol (described in the IEEE 802.3 stand- 
ard, available from the Institute for Electrical and Elec- 

45 tronic Engineers, New York, NY), the maximum packet 
size is approximately 1500 bytes. In order to transmit 
large packets over such size-limited protocols, a routers 
must include interface software or hardware. Briefly, us- 
ing such software or hardware, a sending router splits 

50 the large packet into pieces which are smaller than the 
maximum packet size. These pieces are then transmit- 
ted separately to a receiving node. The receiving node 
then re-assembles the pieces, and the completed large 
packet is forwarded to a subsequent node (this forward- 

55 ing may involve re-splitting the packet for transmission 
over another size-limited protocol). 

Even in protocols which are not size-limited, the 
larger a packet, the more likely that it will be corrupted 
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by noise when sent along a link. Although communica- 
tions laults occur at random, the larger a data packet is, 
the longer it will take to be sent over the link, and thus 
the more likely it is that a fault will occur during the trans- 
mission of the packet. Although it is common for data 5 
packets to be encoded with an error-checking algorithm 
(such as a checksum) which can determine if an error 
has corrupted the information in the packet, such error- 
checking algorithms typically do not provide for a way 
to correct the packet; rather, they can simply determine 
whether the packet is in error. Therefore, when a packet 
is received in error, it is discarded by the receiving router. 
The sending router then re-transmits the packet. The in- 
creased probability of errors in transmitting large pack- 
ets, coupled with the extra time required to transmit such 
packets, can result in a computation burden on network 
routers. 

Summary of the Invention 

In brief summary, the invention as defined in the ap- 
pended claims features a method for updating, at a first 
node of a network of nodes interconnected by links, 
stored information used for routing packets at the first 
node. The first node receives at least one link state 
packet indicating the state of one or more links connect- 
ed to a given node in the network. Thereafter, the first 
node attempts to derive from the received packet or 
packets the states of the indicated links. If the states of 
fewer than all of the links connected to the given node 
are derived, the stored information is updated using the 
derived link states. Later, when a link connected to the 
given node changes from a first state to a second state, 
if the first state of the changed link was indicated in a 
previously sent packet, the first node is sent an amend- 
ed version of the previous packet, which indicates that 
the changed link is in the second state, and nothing else. 
An indicator indicating the amendments made to the 
previous packet is also stored. However, if first state of 
the changed link was not indicated in a previous packet, 
the first node is just sent a packet indicating that the 
changed link is in the second state. 

Preferred embodiments include the following fea- 
tures. 

The indicator is stored in the given node. 

If the changed link subsequently changes from the 
second state back to the first state, the stored indicator 
is retrieved, and a twice amended version of the previ- 
ous packet is formed by removing the amendments in- 
dicated by the indicator, and the twice amended version 
of the packet is sent to the first node. 

The first 'state may be an operative state and the 
second state an inoperative state, in which case each 
link state packet indicates that a link connected to the 
given node is operative by identifying one or more nodes 
that are connected to the operative link, and indicates 
that a link connected to the given node is inoperative by 
omitting identification of one or more nodes that are con- 



nected to the inoperative link. In this embodiment, the 
indicator includes a field for identifying a node and a flag 
bit for indicating the operability of the link connecting the 
identified node to the given node. 

Other features and advantages of the invention will 
be appreciated from the following description of the pre- 
ferred embodiment and from the claims. 

Description of the Preferred Embodiment 

We first briefly describe the drawings. 
Fig. 1 illustrates the contents of a typical LSP. 
Fig. 2 illustrates the contents of a typical CSNP. 
Figs. 3A through 3C illustrate the contents of LSP 
fragments. 

Fig. 4 is a flowchart of an algorithm for updating the 
contents of link state packet storage according to the 
invention. 

Figs. 5A through 5C illustrate the contents of a 
node's link state database. 

Fig. 6 is a flow chart of an algorithm for adding 
neighbors to the fields of the link state database of Figs. 
5A through 50. 

Figs. 7A through 7C illustrate the contents of CSNP 
fragments. 

In the invention, rather than sending long LSPs 
through the network, routers transmit link state informa- 
tion in several smaller fragments. Each fragment is gen- 
erated, transmitted, and used independently of other 
fragments. When one of the fragments is corrupted by 
noise during transmission, only the corrupted fragment 
is re-transmitted. Furthermore, when the state of a link 
changes, only (a revised version of) the affected LSP 
fragment is transmitted. 

Note that the "state" of a link, as used below, is in- 
formation as to whether the link is operative or inopera- 
tive; however, a link state fragments formed according 
to this invention may also include other information 
about the link such as its "cost". Although described in 
terms of updating link operability information, the meth- 
ods described herein are equally applicable to updating 
these other types of link state information. 

A typical set of fragments is illustrated Figs. 3A 
through 3C. Taken together, the fragments illustrated in 
Figs. 3A through 3C contain all of the neighbor fields of 
the prior art LSP of Fig. 1 . However, each fragment con- 
tains only some of the neighbor fields that are contained 
in the prior art LSP of Fig. 1 . Whereas the LSP in Fig. 1 
contains fields for all neighbors (which are numbered 1 
through N), the first fragment, shown in Fig. 3A, contains 
only neighbor fields 1 through K (where K < N); the sec- 
ond fragment, shown in Fig. 3B, contains only neighbor 
fields K+1 through M (where M < N); and the third frag- 
ment, shown in Fig. 3C, contains only neighbor fields 
M+1 through N. 

Each fragment includes a field 10 indicating the 
source node; this field contains the same information as 
the source node field 10 of a prior art LSP (Fig. 1). In 
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addition, each fragment includes a field 1 8 indicating the 
■fragment number', i.e., the fragment's location in the 
set of fragments that includes all of the link state infor- 
mation of a prior art LSP. Note that the fragment in Fig. 
3A is indicated as fragment 1 , the fragment in Fig. 3B is 
indicated as fragment 2, and so on. 

Each fragment also includes a field 1 2 containing a 
sequence number. This field performs a similar function 
to the sequence numbers of complete LSPs; however, 
in this case the sequence number indicates the relative 
age of the fragment among the versions of the fragment 
that have been broadcast by the originating router. Be- 
cause the fragments are independently updated in re- 
sponse to changes in the network, the sequence num- 
bers of various fragments from the same originating 
node may be different; note that the sequence number 
of fragment 1 is 12, but the sequence number of frag- 
ment 2 is 7, and so on. 

Referring to Fig. 4, when a fragment is received by 
a router, the router searches 1 3 for any stored fragments 
having the same source and fragment number as the 
received fragment. If one is found, the router compares 
1 5 the sequence number of the received fragment to the 
sequence number of the stored fragment. If the se- 
quence number of the received fragment is higher, or if 
no stored fragment was found in step 1 3, the received 
fragment is stored 17. The router then computes routes 
through the network based on the link state information 
included in the received fragment (for example, by com- 
puting a routing table using Dijkstra's algorithm). Other- 
wise, if the stored fragment is more current, the stored 
fragment is retained and the received fragment is dis- 
carded 19. 

To enhance the operation of the invention, the rel- 
ative positions of the neighbor fields of the LSP frag- 
ments are carefully maintained. Fig. 5A illustrates the 
contents of a router's link state database 20 (i.e., the 
database in the router that stores the states of all of the 
links connected to the router). The contents and organ- 
ization of the database 20 correspond to the contents 
and organization of the fields in the LSP fragments of 
Figs. 3A through 3C. The first K fields of the database 
are included in the fragment of Fig. 3A, fields K+1 
through M of the database are included in the fragment 
of Fig. 3B, and fields M+1 through N of the database are 
included in the fragment of Fig. 3C. 

Referring to Fig. 5B, as the states of the links 
change, the corresponding fields in the link state data- 
base and the LSP fragments must change. In Fig. SB, 
the links to neighbors M and M+2 have become disa- 
bled. In addition, a new link to a neighbor N+1 has be- 
come enabled. Because the links to neighbors M and 
M+2 are no longer operative, subsequent LSP frag- 
ments should not indicate these neighbors. Although 
these neighbors are to be removed from LSP fragments, 
in the router's database 20, the fields previously occu- 
pied by neighbors M and M+2 are not erased or re-used. 
Rather, the fields for neighbors M and M+2 are marked 



as "empty" (for example, by setting a flag bit); for future 
use, the identity of the neighbor that had previously been 
stored in the field is retained by the field (the identity of 
the previous occupant is illustrated in parentheses in 

5 Fig. 5B). When a new neighbor is added (if there is stor- 
age space available in the router's database 20), rather 
than re-using the fields marked as empty, a new field is 
added to the end of the database. In Fig. 5B, a new field 
has been created for new neighbor N+1 . 

10 New LSP fragments must be issued to convey the 
above link state changes to other nodes in the network. 
These new fragments are illustrated at the bottom of Fig. 
SB. Because the field previously occupied by neighbor 
M is now marked as "empty" in the database 20, the new 

is version of fragment 2 does not have a field for neighbor 
M, and ends with the field for neighbor M-1. Similarly, 
because the field previously occupied by neighbor M+2 
is now "empty" in the database, the new version of frag- 
ment 3 does not have a field for neighbor M+2; the field 

20 for neighbor M+1 is followed immediately by the field for 
neighbor M+3. In addition, because new neighbor N+1 
has been added to the database, the new version of 
fragment 3 ends with a field for the new neighbor N+1 . 
(Alternatively, a new fragment, numbered 4, could be 

25 created to contain the field for neighbor N+1 ). 

The states of the links may change again, for exam- 
ple, in Fig. 5C, the link to neighbor M+2 has again be- 
come enabled. In this case, because neighbor M+2 is 
identified as the previous occupant of a field marked 

30 "empty", neighbor M+2 is not added to the end of the 
data base 20. Rather, the field that previously contained 
neighbor M+2 is modified to not be marked as "empty" 
(i.e., its flag bit is cleared), and thus neighbor M+2 is 
again included in the link state database. 

35 in response to the above changes in the link states, 
a new version of LSP fragment 2 must be issued. This 
new fragment is illustrated at the bottom of Fig. SC. Be- 
cause the field previously marked as "empty" is now oc- 
cupied by neighbor M+2, the new version of fragment 2 

40 has a field for neighbor M+2; the field for neighbor M+1 
is followed immediately by the field for neighbor M+2. 

Referring to Fig. 6, in one algorithm, when a neigh- 
bor is to be added to the link state database 20, a loop 
30, 32, 34 examines the fields in the database which 

45 have the empty bit set. Each field is checked 32 to de- 
termine if it identifies the neighbor to be added (i.e., if 
the neighbor to be added had previously occupied the 
field). If such afield is found, the algorithm clears 36 that 
field's empty bit, thus re-incorporating the neighbor into 

so the database and the LSP fragments. 

If no such field is found, and all of the fields with the 
empty bit set have been checked (i.e., the answer at 
step 34 is "yes"), the algorithm checks 38 if the link state 
database is full. That is, the algorithm checks if there is 

S5 storage space in the link state database for another field. 
If the database is not full, a new field is added 40 to the 
database, and the new neighbor is added to this field. 
However, if the database is full, then one of the "empty" 
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fields must be "garbage collected" and used to store the 
new neighbor. For this purpose, the algorithm selects 
42 a field with the empty bit set, and adds the new neigh- 
bor to this field. The selection strategy may be random, 
or, preferably, the selection may be done on a "least re- 
cently used" basis. In the latter embodiment, each of the 
"empty" fields indicates the length of time that they have 
been marked as empty, and the one that has been 
marked as empty for the longest time is used to store 
the new neighbor. 

The algorithm of Fig. 6 assumes that the node da- 
tabase has more fields than the total number of links 
that may be connected to the node. In an alternative em- 
bodiment, the algorithm can be modified so that, if this 
assumption is false, an error is generated. In this em- 
bodiment, the algorithm returns an error if, during step 
42, a field with the empty bit set is not found. 

The above algorithm for adding and removing fields 
in the node database 20 reduces the extent to which the 
contents of the neighbor fields move in the database and 
in the fragments; the removal or addition of a neighbor 
does not affect the positions of the other neighbors in 
the database or in the fragments. This feature enhances 
the benefits of fragmentation: when the state of one link 
changes, the contents of only one fragment will be af- 
fected by the change. 

If the addition or subtraction of one link caused the 
location of many neighbors to change (as is the case in 
known methods for adding and removing neighbors), 
the contents of many of the fragments would change. 
Thus many fragments would have to be updated in re- 
sponse to a change of state of a single link; as a result, 
transmission overhead would be increased. 

The algorithm of Fig. 6 also reduces the possibility 
that a field for a particular neighbor may move from one 
LSP fragment to another LSP fragment. Such move- 
ments can result in error conditions. For example: if 
node A's neighbor B moved node A's LSP fragment 2 
to node A's LSP fragment from 1 , node A would have to 
broadcast new versions of fragment x and fragment X- 
1 to the network, because the contents of both frag- 
ments changed. If fragment X were broadcast to the net- 
work first, for some period of time before fragment X-1 
was received by the network, the network would be un- 
aware of the link between A and B, because the old ver- 
sion of fragment X-1 would not indicate the existence of 
the link, and the new version of fragment X-1 would not 
yet have been received. This situation may cause an 
error if a node in the network attempts to route a packet 
based on the erroneous assumption that there is no link 
between node A and node B. 

As discussed above, it may often be desirable to 
use CSNPs to compare the contents of the link state 
databases of two routers, for example, two neighboring 
routers. Some particular situations where a CSNP com- 
parison may be desirable are as follows: (1 ) When a link 
is activated, the link state databases of the two routers 
that are newly connected by the link should be com- 



pared. For this purpose, one or both of the connected 
routers may transmit CSNPs to the other router. (2) 
When a new router is first activated (and thus has an 
empty link state database), the new router's neighbors 

s should provide the new router with their stored LSPs. 
For this purpose, the new router may transmit an "emp- 
ty" CSNP to its neighbors, thus requesting an update. 
(3) On a Local Area Network (LAN), the designated rout- 
er (which is responsible for routing and "housekeeping" 

10 duties for the LAN) should regularly verify that all of the 
other LAN routers have received recently transmitted 
LSPs. (This is necessary because routers on a LAN do 
not send acknowledgement messages acknowledging 
the receipt of LSPs). For this purpose, the designated 

75 router broadcasts a CSNP to the other routers on the 
LAN. 

In large networks, there may be many routers, and 
thus the network's CSNPs may become very large. The 
problems that can be caused by large LSPs may also 

20 be caused by large CSNPs. Therefore, in an aspect of 
the invention, large CSNPs are avoided by dispersing 
the information contained in the CSNP, and transmitting 
it in several CSNP fragments. These CSNP fragments 
are illustrated in Figs. 7A through 7C. Each CSNP trag- 
us ment includes several of the pairs 16 included in the 
complete CSNP of Fig. 2. However, the order of the pairs 
16 in the CSNP fragments is not necessarily the same 
as the order of the fragments in the complete CSNP. 
In CSNPs, the order in which the pairs 16 appear is 

30 usually random (and typically depends on the order in 
which the LSPs were added to the originating router's 
linkstate database). In the invention, when creating CS- 
NP fragments, these pairs 16 are ordered. Any suitable 
ordering scheme (e.g., an alphabetical or numeric 

35 scheme) may be used. In a preferred embodiment, the 
source fields 10 of the pairs 16 are used to determine 
an ordering of the pairs. Once all of the pairs 16 are or- 
dered, a range of the pairs (e.g., all pairs with source 
fields numbered 1 through 10) is selected, and those 

40 pairs 16 in the selected range are included in a CSNP 
fragment and transmitted. 

For the sake of example, the first CSNP fragment, 
shown in Fig. 7A, may include the pairs from the sources 
numbered 1 through X, the second CSNP fragment, 

45 shown in Fig. 7B, may include the pairs from sources 
numbered X+1 through Y, and the third CSNP fragment, 
shown in Fig. 7C, may include the pairs from the sources 
numbered Y+1 through Z (where x < Y < Z). Note that, 
although all of the pairs 16 in the selected range are 

so placed in the CSNP fragment, within the CSNP frag- 
ment, the pairs do not have to appear in order (i.e., they 
do not have to be sorted) as shown in Figs. 7 A through 
7C. If desired, the pairs may be randomly arranged with- 
in the CSNP fragment. However, it is preferred to sort 

55 the pairs in the CSNP fragment to increase the efficiency 
with which the CSNP fragment may be parsed and com- 
pared to a receiving router's link state database. 

To facilitate comparison, two additional fields 50, 52 
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are included in the header of the CSNP fragments. 
These fields indicate the range of pairs 16 included in 
the CSNP fragment. Field 50 indicates the source 
number (or name) of the numerically (or alphabetically) 
first pair 16 included in the CSNP fragment. Field 52 in- 5 
dicates the source number (or name) of the numerically 
(or alphabetically) last pair 16 included in the CSNP 
fragment. For example, in Fig. 7A, field 50 indicates that 
source 1 is the start of the range in the CSNP fragment, 
and field 52 indicates that source X is the end of the 
range of the CSNP fragment. 

The inclusion of fields 50, 52 allows the CSNP frag- 
ments to be autonomous, in that their contents are well 
defined, and can be used independently of the other 
fragments. This aspect is discussed in more detail be- 
low. 

When required by the routing algorithm (e.g., under 
any of the conditions set forth in the background above), 
a router forms a CSNP fragment, and transmits it to one 
or more of the other routers in the network. The receiving 
router first compares the CSNP fragment to the receiv- 
ing router's link state database to determine whether 
LSPs for all of the sources mentioned in the CSNP frag- 
ment are stored in the receiving router's link state data- 
base. This comparison allows the receiving router to de- 
termine if there are any LSPs (in the range of the CSNP 
fragment) stored in the link state database of the router 
that originated the CSNP, but not stored in the link state 
database of the receiving router. If there is a LSP miss- 
ing (i.e., not stored in the receiving router's link state da- 
tabase), the receiving router may, for example, send a 
packet to the router that originated the CSNP, request- 
ing a copy of the missing LSP. 

The receiving router also compares the sequence 
numbers in the received CSNP fragment to the se- 
quence numbers in the receiving router's link state da- 
tabase. This comparison allows the receiving router to 
determine the relative age of the LSPs (in the range of 
the CSNP fragment) stored by the receiving router and 
by the originating router. If a LSP stored by the receiving 
router has a higher (i.e., more recent) sequence number 
than that supplied by the corresponding field 12 of the 
received CSNP fragment, the receiving router may (pos- 
sibly depending on the magnitude of the difference be- 
tween the sequence numbers) send a copy of the more 
recent LSP to the router which originated the CSNP. 
Similarly, if a LSP stored by the receiving router has a 
lower (i.e., less recent) sequence number than that sup- 
plied by the corresponding field 12 of the received CSNP 
fragment, the receiving router may send a packet to the 
router that originated the CSNP requesting a copy of the 
more recent LSP. 

Finally, the receiving router checks if any other 
LSPs in its link state database lie in the range specified 
by the CSNP fragment, but do not appear in the CSNP 
fragment. This check allows the receiving router to de- 
termine if there are any LSPs (in the range of the CSNP 
fragment) that are stored in the link state database of 



the receiving router, but are not stored in the link state 
database of the router that originated the CSNP frag- 
ment. If there is a LSP missing (i.e., stored in the receiv- 
ing router's link state database but not appearing in the 
CSNP fragment), the receiving router may, for example, 
send a copy of the missing LSP to the router which orig- 
inated the CSNP. This last step in particular is made pos- 
sible by the inclusion of range fields. 

In this way, a router receiving a CSNP fragment is 
able to compare a portion of its link state database to a 
corresponding portion of the link state database of the 
router that originated the CSNP fragment. The compar- 
ison is as accurate as that provided by known CSNP 
schemes, but can be made from a single CSNP frag- 
ment without regard for the contents of other fragments 
because the comparison is limited to a range of the 
LSPs. Therefore, the CSNP fragments do not all have 
to be received in order to compare the two databases, 
and, as a result, only some of the CSNP fragments need 
by transmitted or received at any one time. 

A CSNP fragment comparison such as discussed 
above is limited to a specified range of the two databas- 
es, and is thus necessarily incomplete. However, even 
when a complete CSNP is used to compare two data- 
bases, the resulting comparison is only approximate, 
because the time delays caused by transmission make 
the CSNP sequence numbers invalid before the CSNP 
arrives at the receiving node. Thus, database compari- 
sons performed through CSNP fragments (for example, 
by transmitting a sequence of fragments having ranges 
which span the entire database) are not necessarily less 
accurate than comparisons performed with complete 
CSNPs. A fragment based comparison may in fact be 
more accurate, because of the reduced transmission 
overhead (and thus less delay) incurred in transmitting 
and comparing the smaller fragments. 

Other Embodiments 

The contents of the CSNP and LSP fragments need 
not be mutually exclusive; rather, some neighbor fields 
may be included in more than one fragment. 

Other information may be included in LSP frag- 
ments. As discussed above, the LSP fragments may in- 
clude link state information in addition to, or instead of, 
an indication of whether the link is operable or inopera- 
ble. For example, the fragment may include link per- 
formance parameters such as "cost". Although de- 
scribed in terms of updating link operability information, 
the methods described herein are equally applicable to 
updating these other types of link state information. 

Furthermore, LSP or CSNP fragments may include 
other fields, for example, fields for verifying the contents 
of the fragments or for aging and invalidating the frag- 
ments. In particular, U.S. Patent Application US-A-5 455 
865 of Radia J. Perlman filed August 24, 1 989 for "Ro- 
bust Packet Routing over a Distributed Network Con- 
taining Malicious Failures", and U.S. Patent Application 
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US-A-5 086 428 of Radia J. Perlman et. al. filed June 9, 
1989 for "Reliable Broadcast of Information in a Wide 
Area Network", describe additional information which 
may be included in CSNP or LSP fragments, and algo- 
rithms for using this information to enhance the robust- 
ness and error recovery of networks. 



Claims 

1. A method for updating, at a recipient node of a net- 
work of nodes interconnected by links, stored infor- 
mation used for routing packets at said first node, 
characterized by the steps of: 

a. sending one or more link state packets (Fig. 
3A) to said recipient node, said packets indicat- 
ing the states (1 4) of some but not all of the links 
connected to a given node in said network, 

b. attempting, at said recipient node, to derive 
from a link state packet (Fig. 3A) sent in step 
(a), the states (14) of the links connected to said 
given node, 

c. updating said stored information used for 
routing packets using the link states (14) de- 
rived in step (b) without regard to other link 
state packets (Fig. 3A) sent to said recipient 
node, and 

d. when a given link connected to said given 
node changes from a first state to a second 
state: 

i. determining (32) whether the first state of 
said given link was indicated in a packet 
(Fig. 3A) previously sent toward said recip- 
ient node, 

ii. if the first state of said given link was not 
indicated in a packet previously sent to- 
ward said first node, generating a packet 
(Fig. 3A) indicating the change of state of 
said given link, and sending said packet to- 
ward said recipient node, otherwise, 

iii. if the first state of said given link was in- 
dicated in a packet previously sent toward 
said first node, generating a replacement 
for the packet previously sent toward said 
first node, said replacement packet (Fig. 
3A) indicating the change of state of said 
given link, storing (36) an indicator identi- 
fying the change of state indicated by said 
replacement packet, and sending said re- 
placement packet toward said recipient 
node. 

2. The method of claim 1 , wherein said indicator is 
stored in said given node. 

3. The method of claim 1 , further comprising 



e. when said given link subsequently changes 
from said second state back to said first state, 
retrieving said stored indicator, forming a fur- 
ther replacement packet (Fig. 3A) by removing 
s the changes identified by said indicator, and 

sending said further replacement packet to- 
ward said first node. 

4. The method of claim 3, wherein 

10 

in said first state said link is operative, and in 
said second state said link is inoperative, 
each link state packet indicates that a link con- 
nected to said given node is operative by iden- 

is tifying one or more nodes (1 4) that are connect- 

ed to the operative link, and indicates that a link 
connected to said given node is inoperative by 
omitting identification of any nodes that are 
connected to the inoperative link, and 

20 said indicator comprises a field for identifying a 

node and a flag bit ("EMPTY") for indicating the 
operability of the link connecting the identified 
node to said given node. 

25 

Patentanspruche 

1. Verfahren zum Updaten, bei einem Empfangskno- 
ten eines Netzwerks von durch Verbindungen mit- 
30 einander verbundenen Knoten, zum Fuhren von 
Paketen beim ersten Knoten verwendeter gespei- 
cherter Informationen, gekennzeichnet durch fol- 
gende Schritte: 

35 a. Senden eines Oder mehrerer Verbindungs- 

zustandspakete (Fig. 3A) zum Empfangskno- 
ten, wobei die Pakete die Zustande (1 4) einiger, 
aber nicht aller der Verbindungen anzeigen, die 
mit einem gegebenen Knoten im Netzwerkver- 

40 bunden sind, 

b. Versuchen, beim Empfangsknoten, aus ei- 
nem Verbindungszustandspaket (Fig. 3A), das 
im Schritt (a) gesendet worden ist, die Zustan- 
de (14) der mit den gegebenen Knoten verbun- 

45 denen Verbindungen abzuleiten, 

c. Updaten der gespeicherten Informationen, 
die zum Fuhren von Paketen verwendet wer- 
den, unter Verwendung der im Schritt (b) abge- 
leiteten Verbindungszustande (14) ohne Be- 
so rucksichtigung anderer zum Empfangsknoten 

gesendeter Verbindungszustandspakete (Fig. 
3A), und 

d. wenn eine gegebene mit dem gegebenen 
Knoten verbundene Verbindung sich von ei- 

55 nem ersten Zustand zu einem zweiten Zustand 

andert: 

i. Bestimmen (32), ob der erste Zustand 
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der gegebenen Verbindung in einem in 
Richtung zum Empfangsknoten gesende- 
ten Paket (Fig. 3A) angezeigt wurde, 

ii. wenn der erste Zustand der gegebenen 
Verbindung nicht in einem zuvor in Rich- & 
tung zum ersten Knoten gesendeten Paket 
angezeigt wurde, Erzeugen eines Pakets 
(Fig. 3A), das die Anderung eines Zustan- 
des der gegebenen Verbindung anzeigt, 
und sonst Senden des Pakets in Richtung io 
zum Empfangsknoten, 

iii. wenn der erste Zustand der gegebenen 
Verbindung in einem zuvor in Richtung 
zum ersten Knoten gesendeten Paket an- 
gezeigt wurde, Erzeugen eines Ersatzes is 
fur das zuvor in Richtung zum ersten Kno- 
ten gesendete Paket, wobei das Ersatzpa- 

ket (Fig. 3A) die Anderung eines Zustan- 
des der gegebenen Verbindung anzeigt, 
Speichern (36) eines Indikators, der die 20 
Anderung eines Zustands identifiziert, der 
durch das Ersatzpaket angezeigt wird, und 
Senden des Ersatzpakets in Richtung zum 
Empfangsknoten. 

25 

2. Verfahren nach Anspruch 1 , wobei der Indikator im 
gegebenen Knoten gespeichert wird. 

3. Verfahren nach Anspruch 1 , das weiterhin folgen- 
des aufweist: 30 

e. wenn sich die gegebene Verbindung nach- 
folgend vom zweiten Zustand zum ersten Zu- 
stand andert, Wiedergewinnen des gespei- 
cherten Indikators, Bilden eines weiteren Er- 35 
satzpakets (Fig. 3A) durch Enffernen der durch 
den Indikator angezeigten Anderungen und 
Senden des weiteren Ersatzpakets in Richtung 
zum ersten Knoten, 

40 

4. Verfahren nach Anspruch 3, wobei 

im ersten Zustand die Verbindung betriebsbe- 
reit ist und im zweiten Zustand die Verbindung 
nicht betriebsbereit ist, 45 
jedes Verbindungszustandspaket anzeigt, daft 
eine mit dem gegebenen Knoten verbundene 
Verbindung betriebsbereit ist, durch Identifizie- 
ren eines oder mehrerer Knoten (14), die mit 
der betriebsbereiten Verbindung verbunden so 
sind, und anzeigt, daB eine mit dem gegebenen 
Knoten verbundene Verbindung 'nicht betriebs- 
bereit ist, durch Weglassen einer Identifikation 
irgendwelcher Knoten, die mit der nicht be- 
triebsbereiten Verbindung verbunden sind, und 55 
der Indikator ein Feld zum Identifizieren eines 
Knotens und ein Flag-Bit ("LEER") zum Anzei- 
gen der Betriebsbereitschaft der Verbindung 



aufweist, die den identifizierten Knoten mit dem 
gegebenen Knoten verbindet. 



Revendications 

1. Proced6 de mise a jour, au niveau d'un noeud re- 
cepteur d'un r6seau de noeuds interconnected par 
des liaisons, d'informations emmagasinees utili- 
ses pour acheminer des paquets au niveau dudit 
premier noeud, caracterise par les Stapes consis- 
tant: 

a. a envoyer un ou plusieurs paquets d'elat de 
liaison (Figure 3A) audit noeud recepteur, les- 
dits paquets indiquant les 6tats (14) de certai- 
nes des liaisons, mais pas de toutes les 
liaisons, reliees a un noeud donne dudit re- 
seau; 

b. a tenter, au niveau dudit noeud recepteur, 
d'obtenir, d'un paquet d'6tat de liaison (figure 
3A) envoye a I'etape (a), les etats (14) des 
liaisons relives audit noeud donn6; 

c. a mettre a jour lesdites informations emma- 
gasinees utilises pour Tacheminement de pa- 
quets en utilisant les etats (14) des liaisons ob- 
tenus a I'etape (b) sans tenir compte d'autres 
paquets d'etet de liaison (figure 3A) envoyes 
audit noeud recepteur; et 

d. lorsqu'une liaison donnSe reliee audit noeud 
donnS passe d'un premier etat a un second 
etat: 

i. a determiner (32) si le premier 6tat de la- 
dite liaison donnee etait indique dans un 
paquet (figure 3A) envoys precSdemment 
vers (edit noeud recepteur, 

ii. si le premier 6tat de lad it e liaison donnee 
n'6tait pas indique dans un paquet envoye 
pr6cedemment vers ledit premier noeud, a 
generer un paquet (figure 3A) indiquant le 
changement d'etat de ladite liaison don- 
nee, et a envoyer ledit paquet vers ledit 
noeud recepteur ; sinon, 

iii. si le premier etat de ladite liaison donnge 
etait indique dans un paquet envoys pre- 
c6demmentvers ledit premier noeud, a ge- 
nerer un remplacement pour le paquet en- 
voy6 precddemment vers ledit premier 
noeud, ledit paquet de remplacement (figu- 
re 3a) indiquant le changement d'etat de 
ladite liaison donn6e, a emmagasiner (36) 
un indicateur identifiant le changement 
d'Stat indique par ledit paquet de rempla- 
cement, et a envoyer ledit paquet de rem- 
placement vers ledit noeud recepteur. 

2. Precede selon la revendication 1 , dans lequel ledit 
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indicateur est emmagasine" dans ledit noeud donne\ 

Proc6d6 selon la revendication 1, consistant, en 
outre: 

5 

e. lorsque ladite liaison donn£e repasse subse- 
quemment dudit second Stat audit premier Stat, 
a recupSrer ledit indicateur emmagasine, a for- 
mer un autre paquet de remplacement (3A) en 
supprimant les modifications identifies par le- 10 
dit indicateur, et a envoyer ledit autre paquet de 
remplacement vers ledit premier noeud. 

Proc6d6 selon la revendication 3, dans lequel: 

15 

dans ledit premier 6tat, ladite liaison est en 
fonctionnement et, dans ledit second 6tat, ladi- 
te liaison est hors fonctionnement; 
chaque paquet d'etat de liaison indique qu'une 
liaison relive audit noeud donn6 est en fonc- 20 
tionnement en identifiant une ou plusieurs 
noeuds (14) qui sont reliefs a la liaison en fonc- 
tionnement, et indique qu'une liaison reli6e 
audit noeud donne" est hors fonctionnement en 
omettant ['identification de tous les noeuds qui 25 
seraient relics a ladite liaison hors fonctionne- 
ment; et 

ledit indicateur comporte une zone pour identi- 
fier un noeud et un bit de drapeau ("EMPTY") 
pour indiquer l'6tat de fonctionnement de la 30 
liaison reliant le noeud identifie" audit noeud 
donne\ 
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